home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-frnetmib-virtual-sma-01.txt < prev    next >
Encoding:
Text File  |  1993-07-08  |  41.7 KB  |  1,231 lines
  1.  
  2.           Draft         Service Management Architecture      June 1993
  3.  
  4.  
  5.  
  6.                         Service Management Architecture
  7.                         for Virtual Connection Services
  8.  
  9.                                   July 1, 1993
  10.  
  11.  
  12.                 Frame Relay Service MIB (frnetmib) Working Group
  13.  
  14.                               Kenneth R. Rodemann
  15.                              AT&T Bell Laboratories
  16.                                 krr@qsun.att.com
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.           1.  Status of this Memo
  27.  
  28.           This document is an Internet Draft.  Internet Drafts are
  29.           working documents of the Internet Engineering Task Force
  30.           (IETF), its Areas, and its Working Groups. Note that other
  31.           groups may also distribute working documents as Internet
  32.           Drafts.
  33.  
  34.           Internet Drafts are draft documents valid for a maximum of
  35.           six months. Internet Drafts may be updated, replaced, or
  36.           obsoleted by other documents at any time.  It is not
  37.           appropriate to use Internet Drafts as reference material or
  38.           to cite them other than as a "working draft" or "work in
  39.           progress."
  40.  
  41.           Please check the I-D abstract listing contained in each
  42.           Internet Draft directory to learn the current status of this
  43.           or any other Internet Draft.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.           Rodemann            Expires Jan 1, 1994             [Page 1]
  55.  
  56.  
  57.  
  58.           Draft         Service Management Architecture      June 1993
  59.  
  60.  
  61.  
  62.           2.  Abstract
  63.  
  64.           This document presents the Service Management Architecture,
  65.           an architectural framework for defining SNMP MIB modules for
  66.           Customer Network Management (CNM) of network services over
  67.           connection-oriented networks.  The work is motivated by the
  68.           fundamental differences in management views and
  69.           functionality between a service provider and a service
  70.           customer.  Differences between service provider and service
  71.           customer include whole-network vs. network-portion view,
  72.           direct vs.  indirect management, and physical vs. logical
  73.           view.  These fundamental differences suggest a difference in
  74.           philosophy between Service Management and Device Management.
  75.           Much work has been done and experience gained in writing
  76.           Device MIB modules for hands-on management of physical
  77.           devices, but defining Service MIB modules is a relatively
  78.           new area and requires the development of a new architectural
  79.           framework.
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.           Rodemann            Expires Jan 1, 1994             [Page 2]
  111.  
  112.  
  113.  
  114.           Draft         Service Management Architecture      June 1993
  115.  
  116.  
  117.  
  118.           3.  Introduction
  119.  
  120.           This document presents the Service Management Architecture,
  121.           an architectural framework for defining SNMP MIB modules for
  122.           Customer Network Management (CNM) of network services over
  123.           shared networks.  Network providers offer a myriad of
  124.           network services, such as X.25, SMDS, Frame Relay, and ATM.
  125.           Some of these provide connection-oriented service, while
  126.           others provide connectionless service. CNM services are
  127.           becoming an important extension of these transport services
  128.           to provide customers with a management window into their
  129.           portion of the shared service. This document focuses on an
  130.           SNMP-based architectural framework for CNM of
  131.           connection-oriented network services.
  132.  
  133.           The purpose of this work is to identify the notion of a
  134.           Service MIB module, and to define an architectural framework
  135.           for its definition that will permit easy extensibility and
  136.           interoperability across various network services.  In order
  137.           to explore and understand how Service and Device management
  138.           differ, consider the following fundamental differences in
  139.           network management functionality between a network service
  140.           provider and a service customer.
  141.  
  142.           First, service providers are responsible for managing the
  143.           entire shared network as a whole, while service customers
  144.           only view and manage their individual portions of the shared
  145.           service.  Because they have a restricted view of the
  146.           network, customers are unable to perform certain network
  147.           management functions in the shared environment.  For
  148.           example, a customer which sets routes for optimized
  149.           throughput of their own traffic may disrupt another
  150.           customer's traffic.  Only the service provider, with a
  151.           complete view of the entire network, is in a position to
  152.           determine routes that allow provisioned access to network
  153.           resources for all customers.
  154.  
  155.           A second fundamental difference in management functionality
  156.           is that service providers manage the network internals
  157.           directly, while customers manage their portion of the shared
  158.           network indirectly.  The service provider is responsible for
  159.           the overall operation of the shared network, so any
  160.           management control offered to customers must first be
  161.           approved (perhaps manually) by the service provider before
  162.           the control request takes effect in the network.
  163.  
  164.  
  165.  
  166.           Rodemann            Expires Jan 1, 1994             [Page 3]
  167.  
  168.  
  169.  
  170.           Draft         Service Management Architecture      June 1993
  171.  
  172.  
  173.  
  174.           Finally, while service providers see a physical view of the
  175.           network, customers see a logical view.  This logical view
  176.           includes the customer's configuration of service access
  177.           points (logical ports) and the virtual connections that run
  178.           between these logical ports.  The customer does not see the
  179.           individual network switches along the paths of its virtual
  180.           connections---setting up physical routes is a responsibility
  181.           of the service provider.
  182.  
  183.           These fundamental differences in network management
  184.           functionality suggest that there is a wholly different
  185.           philosophy between Service Management and Device Management.
  186.           A Device MIB module allows for hands-on management of a
  187.           physical entity.  A Service MIB module provides to customers
  188.           a logical view of the customer's portion of a shared network
  189.           service by modeling the service, not the underlying
  190.           implementation or devices.  Much work has been done and
  191.           experience gained in writing Device MIB modules for hands-on
  192.           management of physical devices, but defining Service MIB
  193.           modules is a relatively new area and requires the
  194.           development of a new architectural framework.
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.           Rodemann            Expires Jan 1, 1994             [Page 4]
  223.  
  224.  
  225.  
  226.           Draft         Service Management Architecture      June 1993
  227.  
  228.  
  229.  
  230.           4.  Service Architecture
  231.  
  232.           A connection-oriented network service offered by a service
  233.           provider can be viewed as a logical configuration of service
  234.           access points (logical ports), access channels, and virtual
  235.           connections (see Figure 1).  Note that the term is used
  236.           instead of 'interface' to distinguish between a service
  237.           access point and a physical device access point.
  238.  
  239.                            +---------------------+
  240.                            |                     |
  241.                         ###@=====================@###
  242.                            |\                    |
  243.                            | =================== |
  244.                            |                    \|
  245.                            |                     @###
  246.                            |                    /|
  247.                            | =================== |
  248.                            |/                    |
  249.                         ###@=====================@###
  250.                            |                     |
  251.                            +---------------------+
  252.  
  253.                Where @   is a service access point (logical port)
  254.                      ### is an access channel
  255.                      === is a virtual connection through
  256.                          the service provider's network
  257.  
  258.                              Figure 1:
  259.              Logical view of a connection-oriented network service,
  260.              including service access points (logical ports),
  261.              access channels, and virtual connections.
  262.  
  263.           The service provider manages the internals of the network
  264.           (switch and trunk acquisition/placement, virtual connection
  265.           provisioning/routing, internal fault detection/correction,
  266.           etc.), so the service customer need not be concerned with
  267.           such aspects.  Instead, the service customer views and
  268.           indirectly manages the components in its logical view of the
  269.           service offering.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.           Rodemann            Expires Jan 1, 1994             [Page 5]
  279.  
  280.  
  281.  
  282.           Draft         Service Management Architecture      June 1993
  283.  
  284.  
  285.  
  286.           A customer may subscribe to the services of more than one
  287.           service provider, with end-to-end virtual connections that
  288.           span multiple service providers' networks.  These
  289.           multi-segment virtual connections can be viewed as a
  290.           concatenation of individual service-provider views (see
  291.           Figure 2).
  292.  
  293.                     +---------+   +---------+   +---------+
  294.                     | Service |   | Service |   | Service |
  295.                     | Provider|   | Provider|   | Provider|
  296.           ------+   |    A    |   |    B    |   |    C    |   +------
  297.                 |   |         |   |         |   |         |   |
  298.            Cust |###@=========@###@=========@###@=========@###| Cust
  299.                 |   |         |   |         |   |         |   |
  300.           ------+   |         |   |         |   |         |   +------
  301.                     +---------+   +---------+   +---------+
  302.  
  303.                                  Figure 2:
  304.                      Logical view of a customer's end-to-end
  305.                      virtual connection that spans across
  306.                      multiple service providers' networks.
  307.                      The end-to-end view is a concatenation
  308.                      of individual service-provider views.
  309.  
  310.           The next section discusses the Service Management
  311.           Architecture, modeled upon the service architecture just
  312.           presented.
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.           Rodemann            Expires Jan 1, 1994             [Page 6]
  335.  
  336.  
  337.  
  338.           Draft         Service Management Architecture      June 1993
  339.  
  340.  
  341.  
  342.           5.  Service Management Architecture
  343.  
  344.           We previously discussed fundamental differences in network
  345.           management functionality between a service provider and a
  346.           service customer.  These fundamental differences led to a
  347.           distinction between a Device MIB module and a Service MIB
  348.           module.  A Service MIB module models the offered service, so
  349.           we now apply the preceding Service Architecture to derive a
  350.           generic Service MIB Module Architecture.
  351.  
  352.           There exist two views of virtual connections within the
  353.           Service Architecture: service-provider views and customer
  354.           end-to-end views.  Service-provider views consist of
  355.           single-segment virtual connections established through a
  356.           single service provider's network.  Customer end-to-end
  357.           views consist of multi-segment end-to-end virtual
  358.           connections that span across multiple service providers'
  359.           networks.  This end-to-end view represents a multi-segment
  360.           virtual connection as a concatenation of individual
  361.           service-provider segments.  We first consider the
  362.           service-provider view, then briefly outline the customer
  363.           end-to-end view.
  364.  
  365.           5.1  Service-Provider View
  366.  
  367.           The Service Architecture identifies three types of service
  368.           objects within the service-provider view: service access
  369.           points (logical ports), access channels, and virtual
  370.           connections.  A customer's logical configuration of service
  371.           objects can be defined in generic terms, regardless of the
  372.           underlying datalink protocol (X.25, Frame Relay, ATM, etc.)
  373.           of the service offering.  Defining the configuration in such
  374.           a protocol-independent fashion will give to customers a
  375.           consistent end-to-end view of interworking services.
  376.  
  377.           5.1.1  Logical Port Table Structure
  378.           This document follows the recommendations of the Internet
  379.           Draft, "Evolution of the Interfaces Group of MIB-II" [1],
  380.           which proposes that each layer in an interface's protocol
  381.           stack have its own entry in the Interfaces Table, and the
  382.           hierarchical relationships between interface layers are
  383.           given in the new ifStack Table.  Because the access channel
  384.           is layered "below" the logical port, the logical port and
  385.           the access channel each have their own ifTable entry and
  386.           ifIndex.
  387.  
  388.  
  389.  
  390.           Rodemann            Expires Jan 1, 1994             [Page 7]
  391.  
  392.  
  393.  
  394.           Draft         Service Management Architecture      June 1993
  395.  
  396.  
  397.  
  398.           Consider the example given in Figure 3 of a typical Frame
  399.           Relay interface stack.  This interface stack is represented
  400.           by two entries in the ifTable, one for the physical layer
  401.           (DS1) and one for the Frame Relay layer.  The ifStackTable
  402.           gives the layering relationship between these two ifTable
  403.           entries.  Of course, there may be other layers involved; for
  404.           example, a Frame Relay service may run over an ATM service,
  405.           which itself runs over a physical layer. Note that since the
  406.           Frame Relay service is modeled as a single entity, each
  407.           logical port's ifIndex value is unique within the service
  408.           provider's offering.
  409.  
  410.  
  411.                                 Interfaces Table
  412.                                 ================
  413.  
  414.                ifIndex                   ifType
  415.             +--------------------------------------------------------+
  416.             |     :      |      |                          |         |
  417.             |     :      |      |                          |         |
  418.             |    50      |......| XX (FR Network Service)  | ....... |
  419.             |     :      |      |                          |         |
  420.             |    74      |......| 18 (DS1)                 | ....... |
  421.             |     :      |      |                          |         |
  422.             |     :      |      |                          |         |
  423.             +--------------------------------------------------------+
  424.  
  425.  
  426.                                  ifStack Table
  427.                                  =============
  428.  
  429.                    ifStackHigherLayer     ifStackLowerLayer
  430.                  +--------------------------------------------+
  431.                  |        :           |          :            |
  432.                  |        50          |          74           |
  433.                  |        :           |          :            |
  434.                  +--------------------------------------------+
  435.  
  436.                                   Figure 3:
  437.                   Example Interfaces and ifStack Table entries for
  438.                   a Frame Relay Network Service over DS1.
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.           Rodemann            Expires Jan 1, 1994             [Page 8]
  447.  
  448.  
  449.  
  450.           Draft         Service Management Architecture      June 1993
  451.  
  452.  
  453.  
  454.           The ifTable contains entries for logical ports of various
  455.           service protocols (for example, Frame Relay logical ports
  456.           and ATM logical ports).  Each of these network services are
  457.           described in a protocol-specific MIB module that contains a
  458.           logical port table indexed by the ifIndex of the associated
  459.           ports.  The ifSpecific variable of a logical port's
  460.           Interfaces Table entry points to the associated
  461.           protocol-specific logical port table.  That table, in turn,
  462.           may contain pointers to other protocol-specific tables, such
  463.           as a link management table.
  464.  
  465.           There are a number of other ifTable variables that may apply
  466.           to the network service logical port.  When defining a
  467.           protocol-specific MIB module, that module definition should
  468.           define the proper use for each of these ifTable variables.
  469.  
  470.           Figure 4 shows an example table structure for a Frame Relay
  471.           logical port. In the figure, the Interfaces Table entry for
  472.           the port contains a pointer to the logical port's
  473.           Frame Relay-specific table.  This entry in turn contains a
  474.           pointer to the proper link management MIB table for that
  475.           logical port.
  476.  
  477.           5.1.2  Virtual Connection Table Structure
  478.           Virtual connections are logical data transport connections
  479.           between a pair of logical ports.  Within the Service
  480.           Management Architecture, the MIB table structure for virtual
  481.           connection tables is similar to the structure for logical
  482.           ports.  All virtual connections, regardless of protocol
  483.           type, are placed in a protocol-independent VC table, and
  484.           each entry in the VC table contains a pointer to the
  485.           associated entry in a protocol-specific virtual connection
  486.           table.  Note that this pointer points to an actual *entry*
  487.           in the protocol-specific table, not just the top of the
  488.           table.  This is necessary because the protocol-specific VC
  489.           table may be indexed differently than the
  490.           protocol-independent VC table.
  491.  
  492.           The protocol-independent VC table contains two entries for
  493.           each virtual connection---one entry for each endpoint of the
  494.           VC.  Each endpoint is separately identified and indexed by a
  495.           tuple (logical port ifIndex, VC id), where the VC id is a
  496.           logical identifier unique to the associated logical port.
  497.           This VC id is assigned by the service provider as it sees
  498.           fit.  The service provider *may* map the VC id directly to
  499.  
  500.  
  501.  
  502.           Rodemann            Expires Jan 1, 1994             [Page 9]
  503.  
  504.  
  505.  
  506.           Draft         Service Management Architecture      June 1993
  507.  
  508.  
  509.  
  510.  
  511.  
  512.                                                          Frame Relay
  513.              Interfaces           Frame Relay            link mgmt
  514.              Table                logical port table     table
  515.           +-----------------+    +-----------------+    +------------+
  516.           |  ifIndex=50     | -->|  portIndex=50   | -->| lmIndex=50 |
  517.           |-----------------| |  |-----------------| |  |------------|
  518.           |        .        | |  |       :         | |  |     :      |
  519.           |        :        | |  |       :         | |  |     :      |
  520.           |-----------------| |  |-----------------| |  +------------+
  521.           |  ifType=XX      | |  |  associated     | |
  522.           |(FR Network Srv) | |  | link mgmt OID  -+--
  523.           |-----------------| |  |-----------------|
  524.           |        .        | |  |       :         |
  525.           |        :        | |  |       :         |
  526.           |-----------------| |  +-----------------+
  527.           | ifSpecific OID -+--
  528.           +-----------------+
  529.  
  530.  
  531.                                Figure 4:
  532.                Example Service Management Architecture table
  533.                structure for a Frame Relay logical port.
  534.  
  535.  
  536.           the addressing scheme used in the underlying protocol (e.g.,
  537.           DLCI for Frame Relay), but this is not necessary.
  538.  
  539.           The set of variables contained in a given row in the VC
  540.           table describe the virtual connection's attributes as viewed
  541.           from the endpoint identified by the row's indexing tuple
  542.           (see Figure 5).  To correlate the opposite endpoints of a
  543.           given virtual connection, each endpoint row in the VC table
  544.           references the other end's row via two variables that
  545.           contain the remote end's logical port ifIndex and VC id.
  546.           Variables associated with the remote end of a given table
  547.           entry can be retrieved by indexing the VC table on the
  548.           values of remote logical port ifIndex and remote VC id.
  549.           Thus, the complete set of attributes for a virtual
  550.           connection are contained in the aggregation of that
  551.           connection's two table entries.
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.           Rodemann            Expires Jan 1, 1994            [Page 10]
  559.  
  560.  
  561.  
  562.           Draft         Service Management Architecture      June 1993
  563.  
  564.  
  565.  
  566.  
  567.  
  568.                          +---------------------+
  569.                          |                     |
  570.                          |                     |
  571.                          |                     |
  572.            ingress --->  |                     |  <---- ingress
  573.                       if1| VC1             VC1 |if2
  574.                       ###@=====================@###
  575.            egress <----  I                     |  ----> egress
  576.                          |                     |
  577.                          |                     |
  578.                          |                     |
  579.                          |                     |
  580.                          +---------------------+
  581.  
  582.  
  583.  
  584.  
  585.                    PROTOCOL-INDEPENDENT VIRTUAL CONNECTION TABLE
  586.                       (indexed on local ifIndex/local VC id)
  587.                    =============================================
  588.  
  589.             local    local  remote   remote
  590.             ifIndex  VC id  ifIndex  VC id      In vars    Out vars
  591.            +---------------+---------------+---+-------+---+-------+
  592.            |   1   |   1   |   2   |   1   |...|       |...|       |
  593.            |   2   |   1   |   1   |   1   |...|       |...|       |
  594.            |   :   |   :   |       |       |   |       |   |       |
  595.            +---------------+---------------+---+-------+---+-------+
  596.  
  597.  
  598.                                  Figure 5:
  599.                 Endpoint views for protocol-independent virtual
  600.                 connection table, and the associated table entries.
  601.  
  602.  
  603.           Note that the protocol-independent virtual connection table
  604.           described above does not yet exist as a part of MIB II.  We
  605.           therefore propose that a Virtual Connection Group defining a
  606.           new table called vcTable be added to the ifMIBObjects MIB
  607.           branch defined in [1].
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.           Rodemann            Expires Jan 1, 1994            [Page 11]
  615.  
  616.  
  617.  
  618.           Draft         Service Management Architecture      June 1993
  619.  
  620.  
  621.  
  622.           This document proposes an initial set of objects for this
  623.           table as follows:
  624.  
  625.                     + local logical port ifIndex
  626.                     + local VC id
  627.                     + remote logical port ifIndex
  628.                     + remote VC id
  629.                     + VC status info
  630.                     + Ingress Octets
  631.                     + Ingress Packets
  632.                     + Egress Octets
  633.                     + Egress Packets
  634.                     + reference to (OID of) protocol-specific virtual
  635.                       connection MIB entry
  636.  
  637.           The vcTable contains an OID that points to associated
  638.           entries in protocol-specific tables. To allow for management
  639.           of interworking service objects, the reverse references must
  640.           also be in place, i.e., references from the
  641.           protocol-specific tables to entries in the vcTable. These
  642.           backward references may be either OIDs or indexes into
  643.           vcTable.
  644.  
  645.           Figure 6 shows how to use vcTable with an associated
  646.           protocol-specific virtual connection table.
  647.  
  648.                                             proto-specific
  649.                            vcTable          VC table
  650.                      +-----------------+    +------------+
  651.                      | local ifIndex   | -->| proto-spec |
  652.                      |-----------------| |  | VC table   |
  653.                      | local VC id     | |  | indexes    |
  654.                      |-----------------| |  |------------|
  655.                      |        :        | |  |     :      |
  656.                      |        :        | |  |     :      |
  657.                      |-----------------| |  |------------|
  658.                      | proto-specific  | |  | vcTable    |
  659.                      |   VC entry OID -+--  | back ref   |
  660.                      +-----------------+    +------------+
  661.  
  662.                                 Figure 6:
  663.              Service Management Architecture vcTable and associated
  664.              protocol-specific virtual connection table relationship.
  665.  
  666.  
  667.  
  668.  
  669.  
  670.           Rodemann            Expires Jan 1, 1994            [Page 12]
  671.  
  672.  
  673.  
  674.           Draft         Service Management Architecture      June 1993
  675.  
  676.  
  677.  
  678.           5.1.3  Example
  679.           The following shows an example scenario of the relationship
  680.           between ifTable, vcTable, and their associated
  681.           protocol-specific tables.  The example also demonstrates how
  682.           the Service Management Architecture provides a consistent
  683.           management view of a service provider's interworking
  684.           service.
  685.  
  686.           Figure 7 gives the configuration of a customer with 5
  687.           logical ports, 3 of which are Frame Relay logical ports
  688.           (lp1, lp2, lp3) and 2 are ATM logical ports (lp4, lp5).  Of
  689.           the customer's 4 virtual connections, 2 are pure Frame Relay
  690.           connections, 1 is a pure ATM connection, and 1 is an
  691.           interworking connection between Frame Relay and ATM.  The
  692.           customer accesses the service via two different types of
  693.           access channels, DS1 and DS3.
  694.  
  695.                             +---------------------+
  696.                     FR   lp1| VC1             VC1 |lp2 FR
  697.                     DS1  ###@=====================@### DS1
  698.                             |\                    |
  699.                             | =================== |
  700.                             | VC2             VC1\|lp3 FR
  701.                             |                     @### DS3
  702.                             | VC1             VC2/|
  703.                             | =================== |
  704.                     ATM  lp4|/                    |lp5 ATM
  705.                     DS3  ###@=====================@### DS3
  706.                             | VC2             VC1 |
  707.                             +---------------------+
  708.  
  709.                                     Figure 7:
  710.               Example customer configuration of an interworking
  711.               service offered by a service provider.  lp<n> is
  712.               a logical port with ifIndex <n>, and VC<n> is a
  713.               VC endpoint with VC id <n> on the associated
  714.               logical port.  FR/ATM are the logical port-specific
  715.               datalink protocols and DS1/DS3 are the specific
  716.               physical layers.
  717.  
  718.           The ifTable has 5 interface stacks (one stack per logical
  719.           port) associated with this service provider's network, as
  720.           shown in Figure 8. The vcTable has 8 entries (one entry for
  721.           each end of the 4 virtual connections), as shown in Figure
  722.           9.
  723.  
  724.  
  725.  
  726.           Rodemann            Expires Jan 1, 1994            [Page 13]
  727.  
  728.  
  729.  
  730.           Draft         Service Management Architecture      June 1993
  731.  
  732.  
  733.  
  734.  
  735.                                     ifTable
  736.                                     ========
  737.  
  738.                 ifIndex        ifType          ifSpecific
  739.                +----------------------------------------------+
  740.                |   1   |...|  XX (FR)  |...| *FR Lport table  |
  741.                |   2   |...|  XX (FR)  |...| *FR Lport table  |
  742.                |   3   |...|  XX (FR)  |...| *FR Lport table  |
  743.                |   4   |...|  YY (ATM) |...| *ATM Lport table |
  744.                |   5   |...|  YY (ATM) |...| *ATM Lport table |
  745.                |   6   |...|  18 (DS1) |...| *DS1 table       |
  746.                |   7   |...|  18 (DS1) |...| *DS1 table       |
  747.                |   8   |...|  30 (DS3) |...| *DS3 table       |
  748.                |   9   |...|  30 (DS3) |...| *DS3 table       |
  749.                |  10   |...|  30 (DS3) |...| *DS3 table       |
  750.                +----------------------------------------------+
  751.  
  752.  
  753.                                         FR Logical Port Table
  754.                ifStack Table            =====================
  755.                =============
  756.                                          Lport
  757.                Higher  Lower             ifIndex
  758.              +---------------+          +------------------------+
  759.              |   1   |   6   |          |   1    |    ......     |
  760.              |   2   |   7   |          |   2    |    ......     |
  761.              |   3   |   8   |          |   3    |    ......     |
  762.              |   4   |   9   |          +------------------------+
  763.              |   5   |  10   |
  764.              +---------------+
  765.                                         ATM Logical Port Table
  766.                                         ======================
  767.  
  768.                                           Lport
  769.                                          ifIndex
  770.                                         +------------------------+
  771.                                         |   4    |    ......     |
  772.                                         |   5    |    ......     |
  773.                                         +------------------------+
  774.  
  775.  
  776.                                       Figure 8:
  777.                 Application of Service Management Architecture
  778.                 (logical port-related tables) for the example.
  779.  
  780.  
  781.  
  782.           Rodemann            Expires Jan 1, 1994            [Page 14]
  783.  
  784.  
  785.  
  786.           Draft         Service Management Architecture      June 1993
  787.  
  788.  
  789.  
  790.           The example shows the forward and backward references
  791.           between related tables.  First, consider the references for
  792.           the logical port-related tables.  The forward reference
  793.           (ifSpecific in ifTable) points to the top of the
  794.           protocol-specific logical port table for the associated
  795.           logical port.  The protocol-specific logical port entry has
  796.           the same index (ifIndex) as the ifTable entry.  The backward
  797.           reference for the logical port-related tables is
  798.           implicit---the associated ifTable entry for a given
  799.           protocol-specific entry is found by indexing the ifTable
  800.           using the value of Lport ifIndex.
  801.  
  802.           Next, consider the references for the virtual
  803.           connection-related tables.  The forward reference within
  804.           vcTable points to the actual entry within the proper
  805.           protocol-specific VC table for the associated endpoint of
  806.           the virtual connection.  This reference must point to the
  807.           actual entry, not the top, of the associated
  808.           protocol-specific VC table because the protocol-specific
  809.           VC table may be indexed differently than vcTable.  For the
  810.           backward references, the example shows two possible methods.
  811.           The FR-specific VC table gives the vcTable's VC id, so the
  812.           associated vcTable entry is found by indexing on
  813.           (local ifIndex, vcTable VC id).  The ATM-specific VC table
  814.           gives an OID pointer back to the associated vcTable entry.
  815.           Both protocol-specific VC tables also indicate if a virtual
  816.           connection is an interworking connection---with a DLCI value
  817.           of -1 for the Frame Relay module, and an interworking flag
  818.           value of 1 for the ATM module.
  819.  
  820.           Finally, consider how to use these references to find the
  821.           remote end of the interworking virtual connection.  From the
  822.           Frame Relay side:
  823.                The index into the FR-specific VC table is (3, 200).
  824.                The remote DLCI for this entry is -1, indicating that
  825.                this is an interworking virtual connection.  The
  826.                backward reference uses the values of local ifIndex=3
  827.                and vcTable VC id=2, so indexing the vcTable on (3, 2),
  828.                we find the remote end is remote ifIndex=4 and
  829.                remote VC id=1 (4, 1).  Now indexing the vcTable on
  830.                (4, 1), we find that this entry points to the first
  831.                entry in the ATM-specific table, which is the proper
  832.                protocol-specific entry for the remote end of the
  833.                virtual connection.
  834.  
  835.  
  836.  
  837.  
  838.           Rodemann            Expires Jan 1, 1994            [Page 15]
  839.  
  840.  
  841.  
  842.           Draft         Service Management Architecture      June 1993
  843.  
  844.  
  845.  
  846.                                   vcTable
  847.                     (indexed on local ifIndex/local VC-id)
  848.                     ======================================
  849.                                                           OID of
  850.           table  local   local  remote   remote      proto-specific
  851.           entry ifIndex  VC id  ifIndex  VC id          VC table
  852.                +-----------------------------------------------------+
  853.             1  |   1   |   1   |   2   |   1   |...| *FR VC entry 1  |
  854.             2  |   1   |   2   |   3   |   1   |...| *FR VC entry 2  |
  855.             3  |   2   |   1   |   1   |   1   |...| *FR VC entry 3  |
  856.             4  |   3   |   1   |   1   |   2   |...| *FR VC entry 4  |
  857.             5  |   3   |   2   |   4   |   1   |...| *FR VC entry 5  |
  858.             6  |   4   |   1   |   3   |   2   |...| *ATM VC entry 1 |
  859.             7  |   4   |   2   |   5   |   1   |...| *ATM VC entry 2 |
  860.             8  |   5   |   1   |   4   |   2   |...| *ATM VC entry 3 |
  861.                +-----------------------------------------------------+
  862.  
  863.                                FR-SPECIFIC VC TABLE
  864.                         (indexed on local ifIndex/local DLCI)
  865.                         =====================================
  866.                 table  local   local  vcTable  remote  remote
  867.                 entry  ifIndex  DLCI  VC id   ifIndex  DLCI
  868.                       +--------------------------------------+
  869.                   1   |   1   |  100 |   1   |   2   |  200  |
  870.                   2   |   1   |  110 |   2   |   3   |  110  |
  871.                   3   |   2   |  200 |   1   |   1   |  100  |
  872.                   4   |   3   |  110 |   1   |   1   |  110  |
  873.                   5   |   3   |  200 |   2   |   4   |   -1  |
  874.                       +--------------------------------------+
  875.  
  876.                             ATM-SPECIFIC VC TABLE
  877.                   (indexed on local ifIndex/local VPI/local VCI)
  878.                   ==============================================
  879.                                    OID of
  880.           table local  local local vcTable  I/W  remote remote remote
  881.           entry ifIndex VPI   VCI  entry    flag ifIndex  VPI   VCI
  882.                ----------------------------------------------------+
  883.             1  |  4   | 100 | 10 | *entry 6 | 1 |   3   |   0 |  0 |
  884.             2  |  4   | 110 | 10 | *entry 7 | 0 |   5   | 100 | 20 |
  885.             3  |  5   | 100 | 20 | *entry 8 | 0 |   4   | 110 | 10 |
  886.                ----------------------------------------------------+
  887.  
  888.                                   Figure 9:
  889.             Application of Service Management Architecture
  890.             (virtual connection-related tables) for the example.
  891.  
  892.  
  893.  
  894.           Rodemann            Expires Jan 1, 1994            [Page 16]
  895.  
  896.  
  897.  
  898.           Draft         Service Management Architecture      June 1993
  899.  
  900.  
  901.  
  902.           From the ATM side:
  903.                The index into the ATM-specific VC table is
  904.                (4, 100, 10).  The I/W flag for this entry is 1,
  905.                indicating that this is an interworking virtual
  906.                connection.  The backward-reference OID for this entry
  907.                points to the sixth entry in vcTable.  We find the
  908.                remote end for the sixth vcTable entry is
  909.                remote ifIndex=3 and remote VC id=2 (3, 2).  Now
  910.                indexing the vcTable on (3, 2), we find that this entry
  911.                points to the fifth entry in the FR-specific table,
  912.                which is the proper protocol-specific entry for the
  913.                remote end of the virtual connection.
  914.  
  915.           5.2  Customer End-to-end View
  916.  
  917.           The customer end-to-end view provides the correlating
  918.           information to view end-to-end virtual connections that span
  919.           through multiple service providers' networks.  This
  920.           end-to-end view represents a multi-segment virtual
  921.           connection as a concatenation of individual service-provider
  922.           segments.  The section of the Service Management
  923.           Architecture is very sketchy.  An adequate definition of
  924.           this view requires much more discussion and experience.
  925.  
  926.           Here is a sketchy initial stab at the information needed for
  927.           this end-to-end view.  This is not in MIB format, i.e.,
  928.           having a table within a table, but this shows the type of
  929.           required information for this view.  An entry in the
  930.           end-to-end MIB module may include:
  931.  
  932.                + end-to-end VC id
  933.                + end-to-end VC status info
  934.                + ordered list of VC Segments:
  935.                     - VC Segment number
  936.                     - VC Segment Provider info
  937.                     - VC Segment status info
  938.                     - point A logical port ifIndex
  939.                     - point A VC id
  940.                     - point B logical port ifIndex
  941.                     - point B VC id
  942.  
  943.           Note the use of generic terms "point A" and "point B".  The
  944.           intent is to refrain from using terms like
  945.           Originating/Terminating and Source/Destination that suggest
  946.           a master-slave type of relationship.  The only relationship
  947.  
  948.  
  949.  
  950.           Rodemann            Expires Jan 1, 1994            [Page 17]
  951.  
  952.  
  953.  
  954.           Draft         Service Management Architecture      June 1993
  955.  
  956.  
  957.  
  958.           to be inferred from the terms point A and point B is the
  959.           polarization or orientation of individual VC segments, i.e.,
  960.           point B of the i'th segment is attached to point A of the
  961.           i+1'st segment.
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.           Rodemann            Expires Jan 1, 1994            [Page 18]
  1007.  
  1008.  
  1009.  
  1010.           Draft         Service Management Architecture      June 1993
  1011.  
  1012.  
  1013.  
  1014.           6.  Summary
  1015.  
  1016.           This document presents the Service Management Architecture
  1017.           for defining Service MIB modules.  The work is motivated by
  1018.           the fundamental differences in management views and
  1019.           functionality between a service provider and a service
  1020.           customer.  Differences between service provider and service
  1021.           customer include whole-network vs. network-portion view,
  1022.           direct vs. indirect management, and physical vs. logical
  1023.           view.  These fundamental differences suggest a difference in
  1024.           philosophy between Service Management and Device Management.
  1025.  
  1026.           The Service Architecture models a customer's view of a
  1027.           shared network service as a logical configuration of logical
  1028.           ports, access channels, and virtual connections.  A service
  1029.           customer indirectly manages the components within its
  1030.           logical view, not the internals of the shared network.
  1031.           Virtual connections that span across multiple service
  1032.           providers' networks are viewed as concatenations of
  1033.           individual service-provider segments.
  1034.  
  1035.           Modeled upon the Service architecture, the Service
  1036.           Management Architecture presents two views of virtual
  1037.           connections: service-provider views and customer end-to-end
  1038.           views.  Service-provider views consist of single-segment
  1039.           virtual connections established through a single service
  1040.           provider's network, while customer end-to-end views consist
  1041.           of multi-segment end-to-end virtual connections that span
  1042.           across multiple service providers' networks.
  1043.  
  1044.           This document discusses more of the service-provider view
  1045.           than it does the customer end-to-end view.  The
  1046.           service-provider view consists of ifTable and a new vcTable
  1047.           for defining configuration, with references to
  1048.           protocol-specific MIB modules.  This structure provides a
  1049.           clean Service Management Architecture that promotes
  1050.           consistent views across various underlying implementations
  1051.           and interworking of services.
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.           Rodemann            Expires Jan 1, 1994            [Page 19]
  1063.  
  1064.  
  1065.  
  1066.           Draft         Service Management Architecture      June 1993
  1067.  
  1068.  
  1069.  
  1070.           7.  References
  1071.  
  1072.           [1]  McCloghrie, K., F. J. Kastenholz, "Evolution of the
  1073.                Interfaces Group of MIB-II", Internet Draft, Interfaces
  1074.                MIB Working Group,  1 June 1993.
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.           Rodemann            Expires Jan 1, 1994            [Page 20]
  1119.  
  1120.  
  1121.  
  1122.           Draft         Service Management Architecture      June 1993
  1123.  
  1124.  
  1125.  
  1126.           8.  Security Considerations
  1127.  
  1128.           Security issues are not discussed in this memo.
  1129.  
  1130.  
  1131.           9.  Author's Address
  1132.  
  1133.                Kenneth R. Rodemann
  1134.                AT&T Bell Laboratories
  1135.                Room 1F-435A
  1136.                101 Crawfords Corner Road
  1137.                PO Box 3030
  1138.                Holmdel, NJ  07733-3030
  1139.                908-949-6229
  1140.                krr@qsun.att.com
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.           Rodemann            Expires Jan 1, 1994            [Page 21]
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.           Table of Contents
  1183.  
  1184.  
  1185.           1.  Status of this Memo.................................   1
  1186.  
  1187.           2.  Abstract............................................   2
  1188.  
  1189.           3.  Introduction........................................   3
  1190.  
  1191.           4.  Service Architecture................................   5
  1192.  
  1193.           5.  Service Management Architecture.....................   7
  1194.               5.1  Service-Provider View..........................   7
  1195.                    5.1.1  Logical Port Table Structure         7
  1196.                    5.1.2  Virtual Connection Table Structure   9
  1197.                    5.1.3  Example                             13
  1198.               5.2  Customer End-to-end View.......................  17
  1199.  
  1200.           6.  Summary.............................................  19
  1201.  
  1202.           7.  References..........................................  20
  1203.  
  1204.           8.  Security Considerations.............................  21
  1205.  
  1206.           9.  Author's Address....................................  21
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.           Rodemann            Expires Jan 1, 1994            [Page 22]
  1231.